Continued advances in computer processor technology have led to not only increased performance, but also increased performance expectations by the users of such computer equipment. The industry has responded to these expectations by creating applications and operating systems that take full advantage of these performance enhancements. However, as additional functionality was added, these applications generally became more complex. This increased complexity, in turn, increased the amount of help and error information needed by a user. In response, developers added additional error messages, dialog boxes, and other windows (messages/windows) in an effort to help the user, to notify the user that an error has occurred, and to notify the user that more information is needed.
Unfortunately, this has resulted in a continually increasing number of messages being generated from applications and the operating system. Additionally, the number of important and trivial messages sent from other users located remotely on the network is increasing rapidly. The most prevalent notification mechanisms for these messages in windows based operating systems are dialog boxes, message boxes, and icons (e.g., tray notify icons) on the operating system's status bar.
Dialog boxes, error messages, message boxes and other notification windows form all of these sources are invasive and often frustrate the user. These boxes may appear to the user as the top-most window and they generally capture control of the user interface. These dialog and message boxes are often accidentally dismissed by users who may be focusing on entering input and not paying attention to the computer monitor. Additionally, the dialog and message boxes often end up hidden behind other windows. The appearance of a box and the accidental dismissal of it frustrates the user because the appearance and accidental dismissal often interfere with the task the user is performing. This often causes the user to become sidetracked from his task and lose his train of thought.
Tray icon notifications, on the other hand, provide an indication on the status bar that a message has arrived. This indication is generally displayed using one of two methods. In the first method, the tray icon provides notification that a message has been received by either changing its shape, blinking, or a combination of the two. The second method places a tray icon on the status bar indicating that a message has been received. This second method then removes the tray icon when the user has seen the message. Two significant limitations of using tray icons are that they are not always obvious when they appear and the tray icon is not always easily identifiable. Another limitation is that the tray icon notification is not practicable in those operating systems that provide the user with an option to hide the status bar because the user will not see the tray icon notification. Additionally, when multiple messages are present, the tray notify icon area can become cluttered making new icons had to spot. As a result of the clutter, the user is often unaware when a new message arrives.
In response to these and other user frustrations with dialog boxes, message boxes and tray icons, application developers have developed individualized notification mechanisms for their applications in an attempt to reduce the user frustration. For example, many e-mail applications now provide some form of message indicating the receipt or presence of e-mail. When a user is logged on to MSN® Messenger Service, for example, a message window appears to inform the user whenever mail arrives. However, control of the user interface is not transferred to this message window. WorldNet® provides a tray icon that blinks when a message arrives and displays a message to indicate the number of messages that have not been read when the user places a cursor over the tray icon.
The development of independent notification mechanisms provide some advantages over prior methods of providing user notification. However, the mechanisms have resulted in inconsistent user interfaces for managing notifications and have introduced other limitations. Each application providing an independent mechanism requires additional overhead. Further, the effort of coding and debugging these individual notification mechanisms and their user interfaces has increased development time and cost of these applications. Unfortunately, users still cannot control how notifications are received and cannot disable the notifications from being received. What is needed is a notification mechanism that is shared between all applications and that provides users with more control over the notifications they receive.